Thanks for updating your PR! It now meets our contributing guidelines. 👍

/review

Hey @adamdotdevin, could you review this PR when you get a chance? It adds Mermaid diagram rendering for packages/ui/. Thanks!

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

Auto-closed by the cleanup bot, not on review. This addresses mermaid in chat markdown (#23688 is a different path — markdown preview mode). Issue #3366 has 24 +1s. Could a maintainer reopen?

Ran this branch locally against streaming markdown from a chat model and hit three correctness issues that don't show up in static-file tests. Filing them together since they share root causes (treating each container as "render-once" and missing concurrency guards).

1. Re-render is skipped after the first chunk (streaming use case)

renderMermaidDiagrams in mermaid.ts selects only containers without data-mermaid-rendered:

const containers = root.querySelectorAll(
  '[data-component="mermaid-diagram"]:not([data-mermaid-rendered])',
)

…and both buildRenderedDOM and buildErrorDOM set data-mermaid-rendered="true" on completion. That means once a container has been processed — even with a parse error — subsequent passes never look at it again.

Repro: the model streams a mermaid block in chunks. Chunk 1 arrives as graph TD\n A (incomplete), mermaid.render throws, buildErrorDOM runs and locks the container. Chunk 2 completes the source to a valid graph TD\n A --> B, but the container is now flagged and we keep showing the error bar forever. Same problem if chunk 1 is valid but chunk 2 changes the diagram structure — the new source is ignored.

Suggested fix: key the skip on source identity, not a boolean flag. Hash the source and store it on two attributes:

const MERMAID_SOURCE_ATTR = "data-mermaid-source-hash"
const MERMAID_LAST_GOOD_HASH = "data-mermaid-last-good-hash"

// Skip if last successful render matches current source.
// Retry if only a failed attempt is recorded — source may now be complete.
if (container.getAttribute(MERMAID_LAST_GOOD_HASH) === sourceHash) continue
if (container.getAttribute(MERMAID_SOURCE_ATTR) === sourceHash) continue
container.setAttribute(MERMAID_SOURCE_ATTR, sourceHash)  // mark attempt
// ...render...
container.setAttribute(MERMAID_LAST_GOOD_HASH, sourceHash)  // mark success

On failure, the existing rendered DOM (from the previous good chunk) stays visible while the model keeps streaming.

2. mermaid.render races between concurrent <Markdown> instances

renderMermaidDiagrams is awaited per-container inside a single call, but nothing prevents two <Markdown> components from calling it simultaneously. Mermaid v11 uses a shared offscreen container for layout measurement and is not concurrency-safe — concurrent renders produce orphan <svg id="mermaid-..."> nodes in document.body and occasionally cross-pollinate output between blocks.

Repro: open a session that has mermaid blocks across multiple historical messages. Every <Markdown> mounts roughly simultaneously and each fires off renderMermaidDiagrams(container). With 3+ blocks it reproduces reliably on Chrome.

Suggested fix: serialise every render through a module-level promise chain:

let mermaidRenderChain: Promise<unknown> = Promise.resolve()

export function renderMermaidDiagrams(root: HTMLElement): Promise<void> {
  const task = mermaidRenderChain.then(() => renderMermaidDiagramsImpl(root))
  mermaidRenderChain = task.catch(() => undefined)
  return task
}

Strictly sequential renders, fully backwards-compatible call signature.

3. Document-level click listeners leak per diagram

In setupControlActions (mermaid.ts:552):

document.addEventListener("click", (e) => {
  if (downloadMenu.style.display === "none") return
  ...
})

This is attached every time a diagram is rendered and never removed. Each new mermaid block in a chat session adds another listener that stays alive for the lifetime of the page. The container.addEventListener("click", ...) a few lines above has the same issue. Re-mounting the <Markdown> (route change, search, etc.) compounds it.

Suggested fix: scope listeners per-render and clean them up. Either store an AbortController per container and trigger .abort() on re-render/unmount:

const ac = new AbortController()
container.addEventListener("click", ..., { signal: ac.signal })
document.addEventListener("click", ..., { signal: ac.signal })
container.setAttribute("data-mermaid-ac", "")  // marker for cleanup
// later, when re-rendering or unmounting: ac.abort()

…or move the outside-click logic to a single delegated listener installed once at module init.

Bonus (minor)

detectTheme() reads the theme synchronously on loadMermaid()'s first call and caches the result for the lifetime of mermaidPromise. If the user toggles theme later, new diagrams still use the original theme. Not urgent — most users don't toggle mid-session — but worth a TODO.

Happy to send a follow-up PR with the three fixes above, @callmeYe — against this branch once reopened, or as a fresh PR after this one merges. The downstream patches are running cleanly in our fork.

CI on this PR was green at the time of auto-close. The bot's "fewer than 2 reactions in a month" trigger is unrelated to code quality — left a +1 and a reopen request earlier.

If there's still appetite from the maintainer side to land this, I'm happy to keep iterating @rekram1-node @rasperepodvipodvert